PROCESO DE ADMINISTRACIÓN DE LA CONFIGURACIÓN DE SOFTWARE

  1. Identificar software, objetivos y componentes
  2. Control de versiones (ej. En caso de que afecte a determinados usuarios del software)
  3. Control de cambio
  4. Auditoría de configuración
  5. Reporte de estado
    1. Qué ocurrió, cuándo, quién lo hizo y que más afectaría (otra cosa o no)

    Esto serviría como métrica para determinar por qué ocurrió lo que ocurrió.

    Existe la posibilidad de basarnos en herramientas

    REPOSITORIO ACS:

    • Repositorio de componentes del proyecto
    • Administracion presentes y pasadas
    • Facilidad para construir una versión según sus componentes
    • Control de errores

    Ej. SVN, CVS

    Pero más orientado a desarrollo

    Ver ejemplo

    VERSIONADO EN EL SOFTWARE

    Un software puede tener más de una versión operativa

    Windows -> Versiones madres y subversiones del original.

    (del lenguaje local)

    v.1.1b v.1.1 -> no la puede actualizar más sino va a perder este cambio v.2.1

    v.1 v.1.1 v.1.2 v.2.0 v.2.1 v.2.2

    v.1.2

    V.1.2 función importante que se incorpora en la v.2

    Otra manera

    v.2.1 Modelo 1

    M.2 V.2.2

    M.3

    Las versiones internacionales generan un problema serio porque duplican la problemática.

    Hoy en día hay tendencia a sacar carteles de la programación. Internamente hay una sola versión. Lo que solía pasar es que hay versiones que afectan una determinada versión.

    Se busca que exista una sola versión y el lenguaje sea solo un agregado.

    V. Inglés política de actualizaciones más reciente, más frecuente.

    El “CURRO” del mantenimiento

    Corrección de errores posterior a la implementación, si el cliente no me paga el mantenimiento=>el software no funciona. Muchos lo aprovechan para solventar el costo de errores, etc.

    El primer mes generalmente está destinado a la etapa de mantenimiento del anterior: implica más recursos que el desarrollo.

    Al final de todo (los seis meses) entrego con errores y fuera de presupuesto. Que no anda bien => como no llegó invento el “curro del mantenimiento”.

    Conclusión:

    • Mantenimiento no es garantía
    • Mantenimiento no es la etapa en la cual recuperamos el dinero.
    • El mantenimiento no es obligatorio.

    Tipos de mantenimiento

    • Correctivo. Errores ->Gratis (en garantía) -> Pagos
    • Adaptativo. Cambios en el contexto
    • Perfectivo -> Mejoras solicitadas o fallas. Para perfeccionar algún aspecto (color, botón, etc.) No es un error.
    • Preventivo . Adelantarse o mejorar previendo nuevos cambios

    Ej: Modificar el software para que ande en un nuevo sistema operativo Ej.

    Problemas

    • Tiempos: Software andando o en producción.
    • Documentación
    • Tecnología obsoleta
    • Software ajeno (tengo que arreglar algo que hizo otro).

    ¿Qué habrá querido hacer? Las soluciones son tantas como programadores existan. Importancia de documentación, controles, métricas.

    Costos de mantenimiento.

    • Gran crecimiento
    • Costos en pesos y en intangibles (en satisfacción del cliente, calidad, mal uso de recursos).
    • Actualmente baja la distribución de los arreglos.

    EFECTOS SECUNDARIOS.

    • Sobre el código.
    • Sobre los datos.
    • Sobre la documentación.

    Mantenimiento del código ajeno.

    • 1ero estudiar, documentar
    • No borrar
    • Mantener el estilo spaghetti, chorizo, tipo de código, cantidad de procedimiento.
    • Nuevas variables
    • Evitar redescubrir.

    La importancia de la documentación: Atado a RFT -> Revisiones técnicas formales.

    Lo que falló en el RFT no es la documentación sino el que lo supervisa.

    ¿Quién debe hacerse cargo del mantenimiento? Asignación de responsabilidades, negociaciones.

    Para evitar que use otro programa (mantenimiento), ofrecido por nosotros.

    REINGENIERÍA.

    Es genérico e implica un cambio en reglas básicas del negocio, cada tanto es necesario hacer reingeniería de software.

    Partir de lo hecho para hacer un cambio nuevo a partir de lo que ya está.

    PASOS DE LA REINGENIERÍA.

    • Análisis de inventario
    • Reestructuración de documentación heredada.
    • Ingeniería inversa-> Parte desde el diseño hacia la programación EXE ejecutable.
    • Reestructuración de código.
    • Reestructuración de datos.
    • Ingeniería progresiva reutilizando -> al revés, una herramienta generadora.

    Otra alternativa: Quiero cambiar una sola parte de esto.

    Total:Tiró todo lo que estaba hecho y arrancó de cero.

    PROBLEMAS

    • ¿Es posible reutilizar? Programación modular, reutilización de software es el gran negocio de vender 2 o 3 a más veces lo mismo.
    • Se da en el momento en que programe el primer sistema. Hacerlo flexible desde el primer momento. En general es posible reutilizar.
    • ¿Hay políticas adecuadas de reutilización?
    • Ponerle políticas es más caro.
    • Se utilizan metodologías que permitan reutilizar.

    El proceso de reutilización

    1. Planes de proyecto
    2. Estructura de costos
    3. Arquitectura de datos
    4. Especificación de objetos y clases
    5. Diseño arquitectónico de datos interfaz y procesos
    6. Código fuente
    7. Documentación de usuario y técnica
    8. Interfases
    9. Datos ej. Tablas
    10. Casos de prueba.

    Muchas veces estoy mejorando en lugar de reutilizar. Está bueno reutilizar pero tiene un límite.